home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 12955 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.4 KB
  1. Path: news.sprintlink.net!datalytics!usenet
  2. From: Rob Stewart <stew@datalytics.com>
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Coding Standards
  5. Date: Fri, 22 Mar 1996 13:17:32 -0500
  6. Organization: Datalytics, Inc
  7. Message-ID: <3152EEBC.3F9F@datalytics.com>
  8. References: <4hj8ek$elu@sam.inforamp.net> <4hktar$5o2@galaxy.ucr.edu> <4hmqol$97j@abacus.abasoft.co.uk> <4hsg8r$pmm@sam.inforamp.net> <4i9o6j$p4l@daisy.pgh.wec.com> <4idskb$pc1@sam.inforamp.net> <314EBD08.43BC@virtus.com> <4io2i7$n9v@sam.inforamp.net>
  9. NNTP-Posting-Host: 204.62.224.71
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0 (WinNT; I)
  14.  
  15. Randy Charles Morin wrote:
  16. > 
  17. > In article <314EBD08.43BC@virtus.com>,
  18. >    "Richard F. Albury" <richard.albury@virtus.com> wrote:
  19. > >// is the standard C++ comment, so I'm not sure I understand your objection.
  20. > 
  21. > What I meant was that the /* */ has been the only standard comment for years.
  22. >  The // comment style is a new proposed standard.
  23. > 
  24.  
  25. It may only be formalized in a standard in the future, but it 
  26. has been part of every C++ compiler since the beginning.  That 
  27. makes it a de facto standard.  This industry has many de facto 
  28. standards upon which we all rely daily.
  29.  
  30. > >>         -a class which can be instantiated with a "new" must have a copy
  31. > >> constructor, a destructor and an assignment operator definition.
  32. > >
  33. > >It's good discipline.  Read Scott Meyers' books for more info.
  34. > 
  35.  
  36. Perhaps it's good discipline, but a copy c'tor and assignment op 
  37. are useful only when you wish to grant that capability.  (To 
  38. deny it, you must declare them private and not implement them, 
  39. of course.)  What I want to know is why instantiating an object 
  40. on the heap requires them.
  41.  
  42. > Unfortunately, if we follow everybodies good discipline guidelines, we would
  43. > miss our October deadline by a few years.
  44. > 
  45. > >>         -optimize code only when you have a problem.
  46. > >>         Why not anticipate the problem?
  47. > >
  48. > >You rarely can.  Read Plauger's writings on style.  One of his sayings is
  49. > >"First make it right, then make it fast."  If performance is an issue, use a
  50. > >profiler.
  51. > 
  52. > You are right.  But the standard explicitly stated that no optimization could
  53. > be done until there was a problem.  I'd hate to see that problem in the field.
  54. >  I'd rather anticipate the problem, most likely by doing exactly what you
  55. > suggested.
  56. > 
  57. > >>         -access functions are to be inline.
  58. > >>         This is the biggest fallacy in programming today.  If you make your
  59. > >> accessors inline, then you have defeated the purpose of data hiding.  If
  60. > >> your data's type changes, then you still have to recompile every object
  61. > >> that accesses the member.
  62. > >
  63. > >Agreed.
  64. > 
  65.  
  66. Compilation firewalls are useful to prevent significant 
  67. recompilation and offer the ability to augment a simple function 
  68. later with more logic to retain the interface in light of an 
  69. implementation change.  However, performance is also an issue.  
  70. If all accessor functions are left as non-inline function calls, 
  71. then your code will bloat and perform worse.
  72.  
  73. The maturity of a class and its use must be considered when 
  74. deciding to inline an accessor.  If the class is well 
  75. established and is unlikely to change, inline accessors make 
  76. great sense.
  77.  
  78. > Thank you.  I have a hard time convincing anybody of this.
  79. > 
  80. > Agrivar
  81.  
  82. -- 
  83. Robert Stewart        | My opinions are usually my own.
  84. Datalytics, Inc.    | stew@datalytics.com
  85.